Studio Not Loading with Large MongoDB Database (10K+ Templates/Assets)



  • I cannot load jsreport Studio when connected to my production MongoDB database. The studio hangs indefinitely and eventually shows "page not responsive". However, the API works perfectly fine - reports generate successfully.
    When I switch to an empty database, the Studio loads without issues, confirming this is related to the data volume. So can we enable paging or lazy loading anything like that in the config ?



  • Could you check F12 network/js dev tools? Is there an error, or just some requests hanging?
    Any errors in the standard server log?



  • No errors are shown in the server logs. It only outputs normal debug entries like:

    2025-10-01 09:48:08 2025-10-01T04:18:08.062Z - debug: OData query on templates
    2025-10-01 09:48:08 2025-10-01T04:18:08.075Z - debug: OData query on settings
    2025-10-01 09:48:08 2025-10-01T04:18:08.112Z - debug: OData query on folders
    2025-10-01 09:48:08 2025-10-01T04:18:08.185Z - debug: OData query on components
    2025-10-01 09:48:08 2025-10-01T04:18:08.192Z - debug: OData query on data
    2025-10-01 09:48:08 2025-10-01T04:18:08.200Z - debug: OData query on tags
    2025-10-01 09:48:08 2025-10-01T04:18:08.207Z - debug: OData query on assets
    2025-10-01 09:48:08 2025-10-01T04:18:08.294Z - debug: OData query on scripts
    2025-10-01 09:48:08 2025-10-01T04:18:08.326Z - debug: OData query on users
    2025-10-01 09:48:08 2025-10-01T04:18:08.333Z - debug: OData query on schedules
    2025-10-01 09:52:37 2025-10-01T04:22:37.025Z - debug: Cleaning up old reports
    2025-10-01 09:52:37 2025-10-01T04:22:37.028Z - debug: Cleaned 0 old reports

    In the browser dev tools (network tab), there are also no failed or hanging requests — everything looks successful. But still, the Studio UI becomes unresponsive and eventually shows “Page is not responsive"



  • I also noticed that if I remove the folders collection from MongoDB, the Studio loads and works fine. But I really need the folders since they represent the hierarchy of my templates



  • I’m testing speed optimization and noticed a big difference between SaaS and local rendering:

    Same template

    SaaS rendering: ~200 ms

    Local rendering: 1400 ms+

    Both environments use the same template and configuration otherwise. I suspect it’s a configuration issue or local setup difference, but I’m not sure what exactly is causing it.



  • Regarding the original question...
    It appears that the studio's JavaScript is freezing the browser. Would it be possible for you to share with me confidentially your workspace? An export or a mongodb dump. You could clean all the data and template content if you need to. You can email me a link where to download it to jan.blaha@jsreport.net

    Regarding rendering time...
    The jsreportonline has limited containers, so your full machine env should actually be faster.
    One thing that comes up to my mind is that the problem could be amount of entities -> slow db and loading.
    Could you check your collections have indexes? The latest jsreport automatically creates indexes.



  • I’ve prepared a backup of my workspace and removed scripts/templates, keeping only the folders collection since that’s the one making the Studio freeze and become unresponsive. I uploaded it to Dropbox and sent the link by email as requested. I also wanted to mention an observation about rendering performance: when testing the same template, jsreport SaaS renders in about 200 ms, while my local instance (using fs store, no MongoDB) takes around 1400 ms. Since both environments use the same template and configuration, I don’t think MongoDB or indexes are involved. I did configure workers in jsreport.config.json, but maybe I missed something—are there specific settings I should check to optimize local rendering speed?



  • There is no extra setting. Try to compare the profile, what is actually the bottleneck
    https://jsreport.net/learn/studio#profiles



  • This rendered from Saas application , this takes only 199ms
    ![alt text](image url)1_1759315192105_Screenshot 2025-10-01 160727.png

    This is rendered from localhost which take almost 2.6 seconds ,

    0_1759315192105_Screenshot 2025-10-01 160648.png
    why handlebar and chrome pdf took this much of time , any idea ?



  • You have two loops in your folder structure.

    folder with shortid 0HYiJb9 has parent itself
    folder AKH3fuS has a parent 2vof8k_ which has parent AKH3fuS

    To fix your workspace
    set to the folder with shortid: 0HYiJb9 the prop folder null to move it to the root
    and set to the shortid: 2vof8k_ the prop folder to null

    I am not sure how this happened. If you will ever be able to deterministically replicate this, we will happily take a look.

    why handlebar and chrome pdf took this much of time , any idea ?

    The only thing that comes to my mind is that the reason is a super throttled CPU.
    Try a different machine, or send me your workspace I can test.



  • Thanks for the clarification. I’ll fix the folder loops in Mongo as you suggested.

    About the workspace – I am using FS store, so could you please confirm if by workspace you mean exporting the FS data ? I just want to be sure I share the correct thing.

    Thanks again for your support.



  • What I noticed is that when I run the official jsreport Docker image directly with an inline config (for example docker run jsreport/jsreport:latest -, it works fast as expected. But when I build my own image based on the official one and copy in my own jsreport.config.json (e.g. FROM jsreport/jsreport:latest then COPY jsreport.config.json /app), the performance becomes slower. Could this be related to the way the config is applied? Is it not recommended to bake the config file directly into the image instead of running with inline config or mounted volumes?



  • You can send the export or compressed data folder...

    I cannot imagine why the perf would be different when using external config. Maybe some kind of disk virtualization/docker/os issue.

    Anyway, what if you test things without Docker first and then troubleshoot the containerization issues?


Log in to reply
 

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.